-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a navigation counter to Documents #7370
Conversation
This is prerequisite work for w3c/performance-timeline#192 - tests and bugs are incoming; I'll update the description as those are completed. |
This seems more like a bfcache counter? It would help to have a little more context for review. |
The idea is that there are several ways that a user can do something that is perceived as a 'navigation' that will not actually reset any state in the document. Currently, I can think of:
There might be more, but these at least would increment this counter. The counter itself would be exposed in PerformanceEntry objects in the Performance Timeline. This allows consumers of that timeline to segment performance events by user navigation, and to understand the performance of the page in that context. See w3c/performance-timeline#182 for more context, and w3c/performance-timeline#192 for the actual proposed integration there. |
We should probably note that this can be a (limited) tracking vector and that it ought to be cleared when the user clears website data. (It's not entirely clear to me that would logically follow from bfcache or app history requirements, although it prolly should.) |
I'm wondering why an app history navigation is treated specifically here, as opposed to a pushState() or replaceState(). The difference between the two is app history navigations have a clear duration, and an additional (async) success or failure signal. But IMO both should be counted as "navigations", and that is what https://github.com/WICG/app-history/#performance-timeline-api-integration envisions. |
Alternately if the intent is really more of "how many times has pageshow been called", then I would change this to "pageshow counter" and change the corresponding performance API from |
Is |
I think that's unfortunately based on a misunderstanding of the app history API. As I said, the only distinction between the two is a duration and async success/failure signal. There's nothing special about navigations from I think the only principled distinction you can make is between cross-document navigations and same-document navigations. Making a distinction based on what API people use is not something the current app history spec infrastructure supports, nor is it something I recommend.
No. |
My understanding of the AppHistory API is that it can do two things for us here:
My goal is to capture, or rather to allow interested developers to capture the idea of user-visible navigation-like transitions, to be able to use that to reason about page performance. In some cases, these transitions are full-document reloads, in others they are bfcache restorations (which may be indistinguishable to the user from the first case, but don't change any document state), and in other cases, they are SPA navs (which don't load a different document, but may change significant page state). Since there are a large number of sites which use the existing history API to record page state information without what the user would see as a 'navigation', I don't know if we can tie this counter to that API. However, the fact that the AppHistory API provides an explicit navigation signal (especially with the 'user-initiated' concept,) it seems that we could leverage that to give developers the option to have those marked as 'navigations' in the performance timeline, by hooking those events up to this counter. Should this discussion be moved to https://github.com/WICG/app-history/issues? |
Right, I'm saying this is not a correct impression. userInitiated applies to all navigations causes by clicking on links or submitting forms, and to zero navigations caused by navigate(). And all navigations can have duration once you use app history, including pushState() ones. I'm OK with any venue for discussion. |
Coming back to this: Tying to the Navigation API, as @domenic says, is probably not possible. I'm fine with any naming that folks think make sense. The intention is to collect "user-perceived" navigation transitions. Updates to state which are effectively the same to a user as a back or forward navigation, but which don't actually create a new browsing context, should update this member. Initially, this should tie into back-forward-cache restorations, and Chrome would like to use this to expose SPA transitions through https://bit.ly/soft-navigation heuristics, hence the more inclusive proposed name. |
I still find the current state, and eventual desired end state, confusing. I re-read the two threads you linked above but between them I think I see about 4 possible proposals floating around. Is there an explainer available? |
I've written up a short motivation, and the concrete proposal, here: https://github.com/clelland/navigationId |
Where is the concrete proposal? I'm afraid that "An SPA navigation is detected" isn't something that makes normative sense. |
@yoavweiss is working on a way to specify that precisely; the latest work is at https://github.com/yoavweiss/soft-navigations/, which is now linked. The heuristics there would be used to trigger a new SoftNavigation performance entry in the performance timeline. Like a back-forward cache restoration, this SPA navigation would update the navigationId to a new value, and include that value in the SoftNavigation entry in the timeline. Subsequent timeline events, up until the next cache restoration or SPA nav, would reference that new navigationId. |
This design seems reasonable to me. I wish it didn't use the phrase "navigation ID", since we're already using that for a spec-level concept that identifies actual navigations in the sense of the navigate |
I think that this can be done differently, entirely within the Performance Timeline API with less intrusion into HTML's navigation algorithms. I've updated w3c/performance-timeline#192, and I'll close this for now. |
(See WHATWG Working Mode: Changes for more details.)
/browsing-the-web.html ( diff )
/browsing-the-web.html ( diff )